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Modem kablowy do podl^czenia urzsLdzen abonenckich i sposob kontroli 
przeptywu danych pomi^dzy modemem kablowym a urz^dzeniem abonenckim 

Przedmiotem wynalazku jest modem kablowy do podJ^czenia urzqdzen 

5 abonenckich i sposob kontroli przepfywu danych pomi^dzy modemem 
kablowym a urz^dzeniem abonenckim. 

Znane i powszechnie uzywane s^ modemy szerokopasmowe. 
przykfadowo modemy kablowe lub modemy xDSL. Sposob dzialania modemow 
kablowych okresia specyfikacja DOCSIS, ktorej nazwa jest skrotem nazwy 

10 angielskiej Dafa-Over-CaWe Se/v/ce /nferfece Spec///caf/ons. 

Stosowane obecnie modemy majq. wbudowan^ obslug? jednego 
Interfejsu okreslonego urz^dzenia abonenckiego, po angielsku Customer 
Premises Equipment, w skrocie CPE. PrzyWadowy modem kablowy 
przedstawiony Jest w zgioszeniu EP 1 109 355 A2 „Cable modem link layer 

15 bridge". Jest to typowy modem pozwalaj^(y na obstug§ tyiko jednego 
interfejsu. Maj^c mozliwosc podl^czenia tyIko jednego interfejsu (przyWadowo, 
port Ethernet), uzytkownik moze podtq^czyc do niego urz^zenie 
multipleksuj^ce, przyWadowo hub Ethernet, ktory pozwoli na podt^czenie do 
niego kilku urz^dzeh. Ograniczeniem jest to, ze istnieje mozliwosc podl^czenia 

20 tyIko poprzez zl^cze Ethernet. Podobnie, moze to bye port USB, co poprzez 
hub USB pozwoli uzytkownikowi na podl^czenie wielu urz^dzeh USB. Jednak 
jak widac z tego przyWadu, uzytkownik ograniczony jest do jednego rodzaju 
\aicza, ktorym moze bye zl^c^e Ethernet lub USB. 

Istot^ wynalazku jest to, ze w modemie szerokopasmowym 

25 zawieraj^cym uWad obslugi warstwy fizycznej MAC oraz most LLC. z ktorym 
komunikuje s\q z uWad warstwy fizycznej i stos IP odpowiedzialny za 
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przetwarzanie pakietow IP, z ktorym wspotpracuje most LLC, do mostu LLC 
poctt^czony jest multiplekser interfejsow urz^dzen abonenckich podl^czonych 
do multipleksera interfejsow, umozliwiaj^cy przesylanie danych pomi^dzy 

30 mostem LLC a jednym z interfejs6w urz^dzeh abonenckich I posiadaj^cy 
tablic^ interfejs6w, w ktorej zapisane s^ dane zarejestrowanych interfejsow, na 
podstawie ktorych okre§la s\q zb pomocq. funkcji identyfikuj^cej interfejs, dia 
ktorego przeznaczona jest ramka o okreslonym adresie fizycznym odbiorcy 
oraz tablic§ adresow MAC urz^dzen z odpowiadajqcymi im identyfikatorami 

35 interfejsow, do ktorych urz^dzenia te s^ podt^czone, przy czym identyfikator 
interfejsu, do ktorego podt^czone jest urz^dzenie o okreslonym adresie MAC 
okresia si? przez funkcj§ sprawdzaj^co-kojarz^cq, a rekordy do tej tablicy 
dodaje siq poprzez funkcj? dodaj^cq, ktora analizuje komendy wysytene przez 
interfejsy. 

40 Interfejs moze bye interfejsem fizycznego urz^dzenia abonenckiego 

kontroiuj^cym przeptyw danych pomi^dzy multiplekserem a sterownikiem tego 
urz^dzenia. 

Interfejs moze bye rowniez interfejsem wirtualnego urzstdzenia 
abonenckiego bfd^cym aplikaq^ kt6rej dziatanie jest uzaleznione od 
45 odebranych pakietow 1 kontroluj^cym przepfyw danych pomi^dzy 
multiplekserem a t^aplikacj^. 

Korzystnie tablica interfejsow okre§la nazw? urz^dzenia, numer 
urz^dzenia ID, adres MAC urzqdzenia. 

Istot^ wynalazku jest rowniez to, ze w sposobie kontroli przeptywu 
50 danych pomi^dzy modemem kablowym a urz^dzeniem abonenckim 
podt^czonym do modemu kablowego, modem wyposaza si§ w multiplekser 
interfejsow, do ktorego podi^cza s\q interfejs urzqdzenia abonenckiego, przy 
czym multiplekser Interfejs6w posiada tablic? Interfejsow, na podstawie ktorej 
okresia si§ identyfikator interfejsu, do ktorego przesyta si§ ramk§ przeznaczona 
55 do urzstdzenia abonenckiego o okreslonym adresie MAC. 

Korzystnie dane wychodz^ce z modemu przesyta si§ najpierw przez 
interfejs urz^dzenia abonenckiego do bufora wyjsciowego, a nast^pnie 
sprawdza si§, czy s^ przeznaczona dIa interfejsow i jesli tak, to przesyta si§ je 
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do zarezerwowanego wczesniej bufora wejsciowego i zwalnia si§ rezerwacj? w 
60 momencie, gdy dane zostan^ z niego odebrane przez wszystkich odbiorcow, 

dia ktorych byfy przeznaczone, a nast^pnie przesyia s\q informacj? do mostu 

LLC o oczekuj^cej na niego ramce w buforze wyj§ciowym. 

Korzystnie dane przychodz^ce do modemu przesyte si§ przez most LLC 

do zarezerwowanego wazesniej bufora wejsciowego, a nast^pnie zwalnia s\q 
65 rezerwacj? tego bufora w momencie, gdy dane zostan^ z niego odebrane 

przez wszystl^icli odbiorcow, dIa kt6rych byfy przeznaczone. 

Korzystnie bufor wejsciowy, kontroluje si§ poprzez ustalanie listy 

odbiorcow dIa ktorych przeznaczona jest ramka, a nast^pnie infomnuje s\q 

odbiorcow o znajduj^cej s\q w buforze ramce, z kazdym poinformowanym 
70 odbiorcq. zwi^kszaj^c licznik poinformowanycli odbiorcow o jeden, a nast^pnie 

gdy odbiorcy odbieraj^ ramk^ z bufora. zwi^ksza si? o jeden licznik odebran, a 

okresia si?, ze dane zostaty odebrane przez wszystkich odbiorcow w 

momencie, gdy licznik odebran zrowna si? z licznikiem poinformowanych 

odbiorcow. 

75 Przedmiot wynalazku jest uwidoczniony w przyWadzie wykonania na 

rysunku, na kt6rym fig. 1 przedstawia schemat blokowy modemu kablowego z 
multiplekserem, fig. 2 przedstawia przepfyw pakietow w warstwach modemu z 
multiplekserem, fig. 3 przedstavwa pot^czenia multipleksera ze strong sieci 
kablowej i strong urz^dzen abonenckich, fig. 4, 5 przedstawiaj^ struktur? ramek 

80 Ethernet przesylanych w systemie, fig. 6 przedstawia struktur? buforow 
wejsciowych i wyjsciowych multipleksera, fig. 7A, 7B, 7C, 8, 9 przedstawiaj^ 
schemat blokowy przeptywu danych w systemie, fig. 10 przedstawia 
uszczegotowion^ struktur? fragmentu modemu kablowego, fig. 1 1 przedstawia 
schemat blokowy funkcji sprawdzaj^co-kojarz^cej, fig. 12 przedstawia schemat 

85 blokowy funkcji dodaj^cej i fig. 13 przedstawia schemat blokowy funkcji 
identyfikuj^cej. 

Fig. 1 przedstawia struktur? modemu kablowego, ktorego most LLC 113 
jest podt^czony do multipleksera 114 interfejsow 115 . 116, 117 urz^dzeh 
abonenckich. Do multipleksera 114 mozna podt^czyc dowolng. liczb? 
90 interfejs6w 115, 116, 117 urz^dzeh, ktore komunikuj^ si? z multiplekserem 114 
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za pomoc^ odpowiednich funkcji. Multiplekser 114 posiada wbudowan^ 
funkcjonalnosc, ktora umozliwia obstug§ przeptywu pakietow pomi^dzy sieci^ 
kablowq. a pod^czonymi do niego interfejsami, kieruj^c odebrane pakiety do 
odpowiednich interfejsow. 

95 Przepfyw danych pomi^dzy sieci^ kablow^ a urzsidzeniem abonenckim 

w modemie kablowym przedstawiony jest na fig. 2, na ktdrej pokazany zostat 
poziom 200 mostu LLC, poziom 210 multipleksera interfejsow, poziom 230 
sterownikow urz^dzen i warstwa fizyczna 241 . Za obs»ug§ przepJywu danych 
przychodz^cych 201 • danych wychodz^cych 202 jest odpowiedzialny most 

100 LLC. Dane przychodz^ce 201 i dane wychodz^ce 202 s^ przesytene przez 
multiplekser 211 interfejsow, do ktorego podt^czone s^ interfejsy 22±, 222, 
223 . 224 poszczegolnych urz^dzen abonenckich, udost^pniaj^ce funkcje 
komunikacji pomi^dzy sterownikiem urz^dzenia a multiplekserem. Dalej dane 
przeptywaj^ przez sterownikl 231 . 232 poszczegolnych urzqdzeh. Jednym z 

105 takich sterownikow moze bye przykJadowo sterownik Ethernet 231, ktory 
obstuguje kolejkl ramek danych przychodz^cych i wychodz^cych. Sterownik 
Ethernet 231 urz^dzenia t^czy siq z warstw^fizyczn^241 danego urz^dzenia. 
Interfejsy urz^dzert wirtualnych nie musz^ by6 pot^czone z warstw^ fizyczn^ 
gdyz urzsidzeniami tymi mog^ bye aplikacje obstuguj^ce okreslone typy 

110 przesylanych ramek. Takie aplikacje mog^ przyWadowo wykonywac funkcje 
diagnostyczne. 

Schemat multipleksera interfejsow i jego pot^czenia ze strong sieci 
kablowej 301 oraz stronq^ urz^dzeh abonenckich 302 przedstawiony jest na fig. 
3. Od strony sieci kablowej 301 multiplekser 311 interfejsow wspotpracuje z 

115 mostem LLC 304, stosem IP 303 oraz ewentualnie z interfejsami 302 urz^dzen 
wirtualnych, ktore przyWadowo mog^ by6 wykorzystywane do obslugi ramek 
kontrolnych przeptywaj^cych przez system. Od strony urzsLdzen abonenckich 
302 podl^czone mog^ bye interfejsy dowolnych urz^dzen, przyWadowo 
interfejsy 322 urzEtdzert wirtualnych, interfejs USB 323, interfejs Ethernet ^4, 

120 interfejs UART 325 oraz interfejsy wszelkich innydi urz^dzen 
wykorzystywanych przez uzytkownika. Jedynym ograniczeniem jest 
koniecznosc zarejestrowania interfejsu w systemie poprzez udost^pnienie 
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swoich danych i funkcji obsluguj^cych komunikacj^ pomiQdzy multiplekserem 

interfejsow a sterownikiem urz^dzenia. 
125 W przedstawionym rozwi^zaniu dane w systemie przesytene w formie 

ramek Ethernet, W systemie mog^ bye przesytene dwa typy ramek: ramki 

danych oraz ramki kontrolne. 

Przykladowy format ramki danych 401 przedstawiony jest na fig. 4. 

Ramki danych 401 typowymi ramkami Ethernet, w sWad ktorych wchodzi 
130 adres odbiorcy 402 . nadawcy 403, typ ramki 404, dane 405 o zmiennej 

dtugosci oraz pole sumy kontrolnej CRC 406 . Pakiety te standardowo 

\A/ykorzystywane s^ przez wszystkie interfejsy. 

Z kolei na fig. 5 przedstawiony jest przykladowy format ramki kontrolnej 

411 . Ramki kontrolne 411 w przedstawionym rozwi^zaniu se|. rowniez ramkami 
135 Ethernet, w ktorych jest okreslony adres odbiorcy 412, adres nadawcy 413, typ 

ramki 414, blok danych kontrolnych sktedaj^cy si? z pola 415 okreslaj^cego 

dtugosc tych danych i samych danych kontrolnych 416 oraz blok sumy 

kontrolnej CRC 417. Ramki kontrolne 411 przesytane s^ zarowno mi^dzy 

interfejsami urz^dzen wirtualnych jak i fizycznych. Przykladowo, dekoder 
140 telewizji satelitarnej moze za pomoc^ ramek kontrolnych odpowiednio sterowac 

prac^ modemu kablowego. W interfejsach lub sterownikach poszczegolnych 

urz^dzen abonenckich mozna zablokowac przeplyw ramek kontrolnych, tak 

aby nie byly one przesytene do urzgdzeh zewn^trznych. 

Aby umozliwic obstug? okreslonego urz^dzenia, nalezy w systemie 
145 zarejestrowac jego interfejs, czyli zestaw funkcji umozliwiajqcych komunikacj? 

pomi^dzy multiplekserem interfejsow a danym urz^dzeniem. Interfejs rejestruje 

siq za pomocq, odpowiedniej funkcji, ktora rejestruje parametry interfejsu w 

tablicy interfejsow multipleksera. Przyktedowa struktura, okreslaj^ca parametry 

interfejsu, przedstawiona jest ponizej: 

150 

typedef struct 
{ 

char *device_name 

/*nazwa interfejsu*/ 
155 device device_id 

/*unikalny identyf ikator interfejsu*/ 
address device_mac_address 

/*adres MAC interfejsu*/ 



flag device_flag 

/*flaga stanu: aktywny/nieaktywny*/ 
flag device_control_f lag 

/*flaga przyjmowania/odrzucania ramek kontrolnych*/ 
transmit_f transmit 

/^funkcja wysyiaj^ca ramk^*/ 
UpDown__f UpDown 

/*funkcja kontroluj^ca flag^ stanu*/ 
long sent_packets 

/*ilosc ramek wysianych przez interfejs*/ 
long received_packets 

/*ilosc ramek odebranych przez interfejs*/ 
} device_handle 

Po starcie systemu, inicjalizowane kolejne interfejsy. Przy inicjalizacji 
budowana jest tablica kojarz^ca identyfikatory interfejsow i adresy MAC im 
przyporz^dkowane. Adresy MAC s^ adresami identyfikuj^cymi okreslone 
urz^dzenie w warstwie sterowania dost^pem do mediow, po angielsku Media 
Access Control, w skrocie MAC. Warstwa ta steruje niskopoziomowymi 
protokofami sprz^towymi. Wedtug modelu sieci OSI {Open Systems Interface) 
warstwa MAC i warstwa LLC {Logical Link Control) tworz^ warstw§ DLC (Dafa 
Unk Control). 

PrzyWadowa struktura tablicy kojarz^cej identyfikatory interfejsow i 
adresy MAC im przyporz^dkowane wygl^da nast^puj^co: 



adres MAC urz^dzenia 


Identyfikator interfejsu 


Urz^dzeniel (MAC1) 


Interfejs urz^dzenial 


Urz^dzenie 2 (MAC2) 


Interfejs urz^dzenia 2 


Urz^dzenie 3 (MAC3) 


Interfejs urz^dzenia 3 


Urz^dzenieSI (MAC31) 


Interfejs urz^dzenia 3 


Urz^dzenie 32 (MAC32) 


Interfejs urz^dzenia 3 







W systemie tworzona jest rowniez druga tablica - tablica interfejsow. 
Jest to tablica, ktorej kolumny okreslajst parametry interfejsow podane podczas 
rejestracji interfejsu w strukturze interfejsu, przyWadowo: nazwa urzgjdzenia, 
numer urz^dzenia ID, adres MAC urz^dzenia. W tablicy interfejsow 
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190 przechowywane dane dotycz^ce tyiko zarejestrowanych interfejsow. 
Rejestracja interfejsu polega na wywolaniu funkcji, ktora jako parametr pobiera 
strukturf danych (stmct device_handle) i zapisuje je do tablicy interfejsow. 

Do jednego interfejsu abonenckiego mog^ bye podl^czone kolejne 
urz^dzenia. Przyktedowo, do interfejsu Ethernet, poprzez hub, moze bye 

195 podl^czonyeh kilka komputerow typu PC. Kazdy z tych komputerow ma sw6j 
wtesny adres MAC. Przy inicjalizaeji systemu, lub tez w trakeie jego dzialania, 
urz^dzenia mog^ wysytec pakiety kontrolne (przyktadowo, pakiety ARP, 
ktorych nazwa pochodzi od angielskiego okreslenia Address Re^lution 
Protocol). Pakiety te przechodz^ wowc^as przez odpowiedni interfejs 

200 urz^dzenia, a ten interfejs przesyte je dalej do bufora wyj§ciowego, sk^d 
pobierane one przez most. Odpowiednia funkcja monitoruje pakiety 
przychodz^ce do bufora wyjsciowego i odczytuje adres MAC nadawcy oraz 
identyfikator interfejsu urz^dzenia. z ktorego pochodzi dany pakiet. Nast^pnie 
sprawdza w tablicy interfejsow, czy wyst^puje w niej dany adres MAC. Jesli 

205 nie, dopisuje informacje o powi^zaniu adresu MAC z identyfikatorem interfejsu 
do tablicy. W trakeie dalszego dzialania systemu, gdy pojawi^ siq pakiety 
przeznaczone dia odpowiedniego adresu MAC, b^dzie on juz skojarzony z 
odpowiednim identyfikatorem interfejsu urz^dzenia i do tego urz^dzenia 
zostanie przestany pakiet. 

210 WysyJanie i odbieranie danych realizowane jest za pomoest bloku 

buforow 521 sWadaj^cego si? z bufbrow wyjsciowych 501 i bufordw 
wejsciowych 511, ktorych idea dziatania i struktura przedstawiona jest na fig. 6. 
Do buforow wyjsciowych 501 kopiowane s^ przez interfejs urzsidzenia dane 
przeznaczone dIa mostu i przechowywane s^ tam do momentu, gdy most 

215 przesle je do kontrolera MAC lub stosu IP. W buforze wyjsciowym 501 s^ 
zarezerwowane obszary pami^i na okreslenie stanu 503 oraz na ramk? 504 . 
Bufor wyjseiowy jest rezerwowany przez interfejs urz^dzenia, a zwalniany 
przez most lub multiplekser interfejsow. Do buforow wej§ciowyeh 511 
kopiowane sq. przez multiplekser interfejsow lub most dane przeznaczone dIa 
220 interfejsow urz^dzen i przechowywane tam do momentu, gdy wszystkie 
interfejsy, dIa ktorych przeznaczone by*y te dane, je odbior^. Kazdy bufor 
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wej^ciowy ma wtasne dwa liczniki: licznik 514 odbiorcow poinformowanych, ze 
czeka na nich ramka w buforze, oraz licznik 515 iiosci odebran ramki z bufora. 
W momencie, gdy licznik 514 odbiorcow poinformowanych i licznik 515 iiosci 
odebrart ramki z bufora wejsclowego 511 si? wyrownaj^ bufor wejsciowy 511 
moze bye zwolniony przez multiplekser i moze zosta6 ponownie wykorzystany. 
Oprocz obszarow dia licaiikow w buforze wejsciowym 511 zarezenwowane 
obszary pami?ci na okreslenie stanu 513 oraz na rarnk? 516. Bufor wejsciowy 
jest rezerwowany przez multiplekser interfejs6w lub most, a zwalniany przez 
230 multiplekser interfejsow. 
^ Procedura wysytenia danych z interfejsu do sieci kablowej 

przedstawiona jest na fig. 7A i 7B. W pierwszym kroku 601 interfejs urz^dzenia 
zetda dost^pu do bufora wyjsciowego wysytajqc komend? jego rezerwacji 
poprzez funkcjf dodaj^c^ do bloku zarz^dzania buforami i gdy bufor jest 
235 dost^pny, otrzymuje jako parametr zwrotny wskaznik do zarezerwowanego 
bufora. Bufor wyjsciowy zostanie zwolniony w momencie, gdy most przesle 
ramk? do kontrolera MAC, lub gdy okaze si§, ze zablokowane jest wysytanie 
danych do mostu. W kolejnym kroku 6^ interfejs kopiuje ramk? do bufora 
wyj§ciowego drogst bezposredni^. Daisza cz^sc procedury obslugiwana jest 
240 przez blok zarz^dzania buforami. I tak w kroku 603 jest sprawdzany typ 
wysytenej ramki. Jesli jest to ramka przeznaczona dIa jednego urz^dzenia 
® (unicast), w kroku 604 nast^puje sprawdzenie, czy wysytena ramka 

przeznaczona jest dIa urz^dzenia podl^czonego do innego interfejsu. Jesli tak, 
lub tez gdy ramka jest przeznaczona dia wielu urz^dzen (multicast, broadcast), 
245 w kroku 605 ma miejsce sprawdzenie, czy istnieje mozliwosc przesytania 
danych do interfejsow, przy czym umozliwienie lub blokowanie przysylania 
danych dokonywane jest za pomoc^ odpowiedniej flagi. Jesli tak, procedura 
z^da dost^pu do bufora wejsciowego i gdy bufor jest dost^pny, rezen^jje ten 
bufor w kroku 606 . Nast^pnie w kroku 607 kopiuje wysyten^ ramk? do tego 
250 bufora. NastQpnie w kroku 6^ jest okre§lana lista odbiorcdw tej ramki poprzez 
podanle ich adresow MAC. Je§li ramka jest przeznaczona dIa jednego 
urz^dzenia (unicast), na liscie znajdzie si§ tyiko jeden odbiorca. Jesli jest to 
ramka przeznaczona dIa wielu urz^dzeh (multicast, broadcast), na liscie znajd^ 
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si? wszystkie urz^dzenia o adresach MAC dost^pnych w tablicy MAC/CPE. W 
255 kroku 623 nast^puje wystenie pierwszemu odbiorcy z listy poprzez funkcj? 
sprawdzajSLC^ i identyfikujqc^ informacji (wskaznika do bufora) o ramce 
przeznaczonej dia niego, oczekuj^cej w buforze wej§ciowym. Licznik 
poinformowanych odbiorcow zostaje zwi^kszony o 1 w kroku 624, a w kroku 
625 procedura sprawdza, czy poinformowani zostali wszyscy odbiorcy. Jesli 
260 nie, przechodzi do nast^pnego odbiorcy w kroku ^6. Gdy poinformowani 
zostan^ wszyscy odbiorcy, lub tez gdy ramka nie jest wysyiana do interfejsow, 
procedura sprawdza w kroku 610 . czy ramk§ mozna przestec do mostu LLC 
(za pomoc^ odpowiednlej flagi mozna umozliwic b^dz zablokowac przesytanie 
danych do mostu). Jesli tak, w kroku 612 do mostu LLC zostaje przesteny 
265 adres bufora, w ktorym czeka na niego ramka. Gdy most pobierze z niego t? 
ramk§, to zwoini on bufor do kolejnego wykorzystania. Bufor moze bye rowniez 
zwalniany przez multiplekser interfejsow w kroku 611 . jesli ramka nie jest 
wysylana do mostu. Nast^pnie w kroku 613 sprawdza si? odbior danych z 
bufora wejsciowego, co jest realizowane przez procedure z fig. 7C. 
270 Procedura sprawdzania odbioru danych z bufora wejsciowego, kt6ra jest 

przedstawiona na fig. 7C, rozpoczyna si? w kroku 631 od udost?pnienia 
lokainego licznika poinformowanych odbiorc6w funkcjom interfejs6w. Nast?pnie 
w kroku 632 ma miejsce sprawdzenie. czy wszyscy odbiorcy odebrali ramk? 
poprzez por6wnanie licznika cKlbiorc6w poinformowanych oraz licznika ilosca 
275 pobran. Jesli tak, to w kroku 633 jest zwalniany bufor wejsciowy. Jesli nie, 
^ procedura jest zakonczona w kroku 634 . a bufor wejsciowy zostanie zwolniony 

przez funkcj? pobieraj^c^ dane z bufora jako ostatnia. 

Gdy most odbierze ramk?, post?puje dalej tak, jak typowy most modemu 
kablowego, to znaczy kieruje ramk? w stron? sieca kablowej. Dzialanie mostu 
280 nie jest istotne dIa tego opisu. 

Procedura odbioru danych przedstawiona jest na fig. 8. W kroku 701 
most zqda dost?pu do bufora wejsciowego i gdy jest on dost?pny, rezerwuje 
ten bufor. Nast?pnie w kroku 702 ramka przesylana jest do bufora 
wejsciowego, a w kroku 703 procedura bloku zarz^dzania buforami sprawdza, 
285 jakiego typu jest ta ramka. Jesli ramka przeznaczona jest dIa jednego odbiorcy 
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(unicast), w kroku 704 okreSiony zostaje odbiorca ramki poprzez okreslenie 
adresu MAC odbiorcy. Nast^pnie w kroku 705 sprawdza s\q w tablicy 
MAC/CPE, czy odbiorca ten jest dost^pny. Jesli tak, w kroku 706 wyslana 
zostaje do niego informacja (wskaznik do bufora) o oczekuj^cej ramce 
290 (poprzez funkq^ sprawdzajqco-kojarz^c^ oraz funkq? IdentyfikuJ^csO. a licznik 
poinformowanych odbiorcow zostaje zwi^kszony o jeden w kroku 707. Je§ll jest 
to ramka przeznaczona dia wielu odbiorcow (multicast/broadcast), w kroku 709 
okresia si? list? odbiorcow ramki, przy czym na lisde znajd^ si? wszystkie 
aktywne adresy MAC. W kroku 710 ma miejsce wysfanie pierwszemu odbiorcy 
295 z listy informacji o ramce przeznaczonej dIa niego, oczekuj^cej w buforze 
wejsciowym, a licznik poinformowanych odbiorcow zostaje zwi?kszony o 1 w 
kroku 711 . W kroku 712 procedura sprawdza, czy poinformowani zostali 
wszyscy odbiorcy. Jesli nie, przechodzi do nast?pnego odbiorcy w kroku 713. 
Gdy poinformowani zostan^ wszyscy odbiorcy, w kroku 708 sprawdza si? 
300 odbior danych z bufora wejsciowego, co jest realizowane przez procedur? 
przedstawion^.na fig. 7C. 

Gdy interfejs urz^dzenia zostanie poinformowany o oczekuj^cej dia 
niego ramce w buforze wejsciowym, c^li jednoczesnie otrzyma wskaznik do 
tego bufora, uruchamia swoj^ procedur? odbioru ramki, przedstawionq. na fig. 
305 9. I tak w kroku 801 procedura pobiera z bufora wejsciowego ramk? drog^ 
bezposredni^ gdyz zna jego adres i przesyte j^ do urz^dzenia. Nast?pnie, w 
kroku 802 licznik ilosci odebran ramki z tego bufora zostaje zwi?kszony o 1 , a 
w kroku 803 interfejs sprawdza, czy wszyscy odbiorcy odebrali ramk? poprzez 
porownanie licznika odbiorcow poinformowanych oraz licznika ilosci pobran. 
310 Sprawdzenle to ma miejsce, jesli licznik odbiorcow poinformowanych zostal 
wczesniej udost?pniony dIa tej funkcji. Jesli nie, sprawdzenie nie odbywa si?. 
Jesli wszyscy odbiorcy odebrali ramk?, oznacza to te ta funkcja odebrate 
ramk? jako ostatnia i zwalnia bufor wej§ciowy w kroku 804. Je§li nie, procedura 
jest zakohczona w kroku 805 . a bufor wej§ciowy b?dzie zwolniony przez 
315 funkcj? innego interfejsu. 

Fig. 10 przedstawia koricow^ cz?sc mostu LLC 913, multiplekser 
interfejsow 914 i podl^czony do niego zestaw 915 Interfejsow CPE sWadaj^cy 
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siq z interfejsow 909, 910, 911, 912. Na koncx)w^ cz^sc mostu LLC 913 sWada 
si^ blok buforow wejsciowych 901 . przechowuj^cych dane przeznaczone dia 
320 interfejsow CPE oraz blok buforow wyjSciowych 902, przechowuj^cych dane 
wysylane przez interfejsy CPE, a takze blok 903 zarz^dzania buforami, 
wykonuj^cy funkcje rezerwacjl i zwalnlania buforow. Natomlast na multlplekser 
interfejsow 914 sWada siQ tablica MAC/CPE 904, funkcja sprawdzaj^ca. ktora 
sprawdza w tablicy MAC, czy do modemu podt^czone jest urz^dzenie o 
325 adresie MAC podanym w pakiecie i jesli taK to przesyta pakiet dalej, a jesli nie, 
odrzuca ten pakiet. Na multiplekser interfejsow 914 sktada s\q rdwniez funkqa 
dodaj^ca 906. ktora analizuje informacje przychodz^ce od interfejsow CPE i 
sprawdza, czy adres MAC nadawcy jest juz zapisany w tablicy MAC, a jesli nie 
to dodaje go do tej tablicy MAC. Na multiplekser interfejsow 914 sWada si? 
330 takze tablica interfejsow 907 i funkcja identyfikuj^ca 908, ktora na podstawie 
identyfikatora CPE przekazanego przez funkcj? sprawdzaj^co-kojarz^c^ 905 
pobiera z tablicy interfejsow 907 dane identyfikujqce okreslony interfejs i 
przekazuje do niego okreslone informacje. 

Funkcja sprawdzajsico-kojarz^ca, kt6rej schemat blokowy jest 
335 przedstawlony na fig. 1 1 , w kroku ^0 jako parametr wejsciowy odczytuje adres 
MAC, dIa kt6rego przeznaczony jest pakiet. Nast^pnie w kroku 921 sprawdza, 
czy w tablicy MAC/CPE znajduje s\q rekord dotycz^cy taklego adresu MAC. 
^ Je§li nie, oznacza to, ze dany adres MAC nie jest obstugiwany przez 

multiplekser interfejsow, co oznacza, ie urz^dzenie o takim adresie MAC nie 
340 jest widziane przez multiplekser i w kroku 922 nast^puje odrzucenie pakletu. W 
przypadku, gdy funkcja odczytuje identyfikator interfejsu CPE. do ktorego jest 
podlqczone urz^dzenie o danym adresie MAC, w kroku 923 ma miejsce 
odczytanie identyfikatora CPE, a nast^pnie, w kroku 924 identyfikator ten jest 
podawany, co umozliwia przesianie informacji do odpowiedniego interfejsu. 
345 Na fig. 12 jest przedstawiony schemat blokowy funkcja dodaj^cej, ktora 

analizuje informacje wysylane z interfejsow CPE do mostu LLC. DIa kazdej 
przesytanej informacji, po odczytaniu adresu MAC jej nadawcy w kroku 930 . 
nast^puje sprawdzenie w kroku 931, czy w tablicy MAC/CPE wyst^puje juz taki 
adres MAC. Jesli nie, w kroku 932 jest on dodawany do tablicy wraz z 
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350 informacj% z jakiego interfejsu CPE nadszectt ten pakiet. Jesli adres MAC jest 
juz w tablicy, w kroku 933 nie podejmowane zadne dziatenia. 

Fig. 13 przedstawia funkcj§ identyfikuj^cq, ktora w kroku 940 odczytuje 
identyfikator CPE. dia ktorego przeznaczona jest pr2esy*ana ramka. Nast^pnie, 
w kroku 941 w tablicy interfejs6w (w ktorej zapisane Informacje o 

355 zarejestrowanych interfejsadi) odnajduje funkcj? danego interfejsu, ktora 
przeSie do niego dane, a nast^pnie w kroku 942, przekazuje ramk^ do tej 
funkcji, a funkcja ta przekazuje j^do danego interfejsu. 

W modemie informacje przesylane ssl roznymi sciezkami w zalezno§ci 
od typu przesytenych informacji. I tak komunikaty o pakiecie dia okreslonego 

360 MAC oczekuj^cym w okreslonym buforze przesytane sciezk^ od buforow 
wejsciowych poprzez blok zarz^dzania i funkcja sprawdzaj^cq do interfejsu 
CPE. Dane pobierane przez interfejsy z okreslonego bufora przesytene s^ 
bezposrednio pomi^dzy buforami wejsciowymi a interfejsami CPE. Z kolei 
zqdania rezervt/acji bufora i komunikaty zwolnienia bufora (z pomini^ciem 

365 funkcji dodaj^cej) przesytane sciezk^ od interfejs6w CPE poprzez funkcj? 
dodaj^c^ i blok zarz^dzania do bufor6w wyj§ciowych. Natomiast dane 
wysylane przez interfejsy do okreslonego bufora s^ przesytane bezposrednio 
pomi^zy buforami wyjSciowymi a interfejsami CPE. 

Przedstawione powyzej rozwi^zanie pozwala na bezposrednie podi^czenie 

370 do modemu dowolnej liczby interfejs6w roznego typu urz^dzen fizycznych, 
przykladowo komputerow PC czy dekoderow telewizji cyfrowej, podl^czonych 
przez port USB, Ethernet lub port szerego\wy- Powyzsze rozwi^zanie pozwala 
rowniez na bezposrednie podl^czenie urz^dzen wirtualnych, przykladowo 
aplikacji obstuguj^cych przeplywaj^ce przez siec ramki kontrolne. 
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Zastrzezenia patentowe 

1. Modem szerokopasmowy zawieraj^cy ukfad obshjgi warstwy fizycznej 
^ MAC, most LLC, z ktorym komunikuje si§ z uWad warstwy fizycznej oraz stos 

5 IP odpowledzialny za przetwarzanie pakietdw IP, z ktdrym wspolpracuje most 
LLC, znamienny tym, ze do mostu LLC ( 113) podt^czony jest multiplekser 
(114) interfejsow (115, 116, 117, 909, 910, 911, 912) urz^dzen abonenckich 
podl^czonych do multipleksera interfejsow (114). umozliwiaj^cy przesytenie 
danych pomi^dzy mostem LLC ( 113 ) a jednym z interfejsow (115), (US, HZ, 
10 909, 910, 911. 912) urz^dzen abonenckich i posiadaj^cy tablic^ (907) 
interfejsow, w kt6rej zapisane dane zarejestrowanych interfejsow (115. 116, 
117, 909 . 910 . 911, 912) . na podstawie ktorych okresia si? za pomocsi funkcjl 
identyfikuj^cej ( 908) Interfejs, dia ktorego przeznaczona jest ramka o 
okre§lonym adresie fizycznym odblorcy oraz tablic? (904) adresow MAC 
@ 15 urz^dzen z odpowiadaj^cymi im identyfikatorami interfejsow (115, 116 . 117. 

909. 910. 911. 912) . do ktorych urz^dzenia te podi^czone, przy czym 
identyfikator interfejsu, do ktorego podt^czone jest urz^dzenie o okreslonym 
adresie MAC okresia si? przez funkcj? sprawdzaj^co-kojarz^c^ (905), a 
rekordy do tej tablicy dodaje si? poprzez funkcj? dodaj^c^ (906), ktora 
20 analizuje komendy wysytane przez interfejsy (115, 116, 117, 909, 910, 911. 
912). 

2. Modem szerokopasmowy wed^ug zastrz. 1 , znamienny tym, ze interfejs 
(115, 116, HZ, 909, 910, 911, 912) jest interfejsem fizycznego urz^dzenia 

25 abonenckiego kontroluj^cym przepfyw danych pomi?dzy multiplekserem a 
sterownikiem tego urz^dzenia. 
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3. Modem szerokopasmowy wedtug zastrz. 1 , znamienny tym, ze interfejs 
(115 , 116 , 117 , 909, 910 . 911. 912) jest interfejsem wirtualnego urz^dzenia 

30 abonenckiego b^d^cym aplikacj^ ktorej dzialanie jest uzaleznione od 
odebranych pakietow i kontroluj^cym przeptyw danych pomi^dzy 
multiplekserem a t^apiikacj^. 

4. Modem szerokopasmowy wedlug zastrz. 1, znamienny tym, ze tablica 
35 interfejsow (904) okresia nazw§ urz^dzenia, numer urz^dzenia ID, adres MAC 

urzqdzenia, 

5. Sposob kontroli przeplywu danych pomi^dzy modemem kablowym a 
urz^dzeniem abonenckim podt^czonym do modemu kablowego, znamienny 

40 tym, ze modem wyposaza si§ w multiplekser interfejsow, do ktorego podt^cza 
si^ interfejs urz^dzenia abonenckiego, przy czym multiplekser interfejsow 
posiada tablic^ interfejsow, na podstawie ktorej okresia si? identyfikator 
interfejsu, do ktorego przesyte si? ramk? przeznaczon^ do urz^dzenia 
abonenckiego o okreslonym adresie MAC. 

45 

6. Sposob kontroli przeplywu danycii wedlug zastrz. 5, znamienny tym, ze 
dane wychodz^ce z modemu przesyte si? najpierw przez interfejs urz^dzenia 
abonenckiego do bufora wyjsciowego, a nast?pnie sprawdza si?, czy s^ 
przeznaczone dia interfejsow i jesli tak, to przesyla si? je do zarezerwowanego 

50 wczesniej bufora wejsciowego i zwalnia si? rezerwacj? w momencie, gdy dane 
zostan^ z niego odebrane przez wszystkich odbiorcow, dia ktorych byty 
przeznaczone, a nast?pnie przesyla si? informacj? do mostu LLC o 
oczekuj^cej na niego ramce w buforze wyjsciowym. 

55 7. Sposob kontroli przeptywu danych wedtug zastrz. 5. znamienny tym, ze 
dane przychodz^ce do modemu przesyta si? przez most LLC do 
zarezerwowanego wczesniej bufora wejsciowego, a nast?pnie zwalnia si? 
rezerwacj? tego bufora w momencie, gdy dane zostan^ z niego odebrane 
przez wszystkich odbiorcow, dia ktorych byty przeznaczone. 
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60 8. Spos6b kontroli przeptywu danych wedtug zastrz. 5, znamienny tym, ze 
bufor wejsciowy, kontroluje si§ poprzez ustalanie listy odbiorcow dia ktorych 
przeznaczona jest ramka, a nast^pnie informuje s\q odbiorcow o znajduj^cej 
siQ w buforze ramce, z kazdym poinformowanym odbiorcq. zwi^kszaj^c licznik 
poinformowanych odbiorcow o jeden, a nast^pnie gdy odbiorcy odbieraj^ 

65 rarnk^ z bufora, zwi^ksza s\q o jeden licznik odebran, a okresia s\q, ze dane 
zostaly odebrane przez wszystkich odbiorc6w w momencie, gdy licznik 
odebrart zrowna s\q z licznikiem poinformowanych odbiorcow. 
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Cable modem for connecting customer premises equipment and a method of controlling 
data transfer between the cable modem and customer premises equipment 

The object of the invention is a cable modem for connecting customer premises 
5 equipment and a method of controlling data transfer between the cable modem and 

customer premises equipment. 

There are broadband modems known and commonly used, for example cable 
modems or xDSL modems. The method of operation of cable modems is determined 
by DOCSIS specification, the name of which is a short name of English Data-Over- 

10 Cable Service Interface Specifications. 

Modems, which are currently applied, have a built-in service of one interface of a 
specific subscriber device, the English name of which is Customer Premises 
Equipment, with a short name of CPE. Exemplary cable modem is presented in 

15 application EP 1 109 355 A2 'Cable modem link layer bridge'. This is a typical 
modem, which allows servicing only one interface. Having the opportunity of 
connecting only one interface (for example an Ethemet port), the user can connect a 
multiplexer to it, for example an Ethemet hub, which will allow to connect a few 

20 devices to it. A limitation is that there is a possibility of connecting only through an 
Ethemet connection. Similarly, it can be a USB port, which through a USB hub w' 



allow the user to connect many USB devices. However as one can see in this 
example, the user is limited to one type of connection, which can be an Ethemet or 
USB connection. 

The essence of the invention is that a broadband modem including a physical MAC 
layer service system and an LLC bridge, with which the system of physical layer and 
IP stack, responsible for processing IP packets communicate, with which LLC 
bridge co-operates. An multiplexer of interfaces of customer premises equipment 
connected to the interfaces multiplexer is connected to the LLC bridge, which 
enables sending data between the LLC bridge and one of the interfaces of customer 
premises equipment. It possesses a table of interfaces, in which data of registered 
interfaces are recorded, based on which, by means of an identifying function, the 
interface is defined, to which a frame is addressed with a specific physical address of 
recipient and a table of MAC addresses of devices, with identifiers of corresponding 
interfaces, to which these devices are connected, while the interface identifier, to 
which the device, with a defined MAC address is connected, is determined by means 
of a check and associate function. Records in this table are added by means of an 
adding function, which analyzes commands sent by interfaces. 

The interface can be an interface of a physical customer premises equipment, which 
controls transfer of data between the multiplexer and a driver of this device. 
The interface can also be an interface of a virtual customer premises equipment, 
which is an application, the operation of which depends on received packets and the 
interface can control data transfer between the multiplexer and this application. 
The table favorably determines the name of the device, the ID number of the device, 
and the MAC address of the device. 

This is also the essence of the invention that in the method of control of data transfi 



between the cable modem and customer premises equipment connected to cable 
modem, the modem is equipped with an interfaces multiplexer, to which customer 
premises equipment interface is connected, while the interfaces multiplexer has a 
table of interfaces, based on which the interface identifier is determined. A frame, 
designated to the customer premises equipment with a specific MAC address is sent 
to the interface identifier. 

55 Favorably the data outgoing from the modem are first sent through the interface 

of customer premises equipment to the output buffer and next a check is performed, 
if they are addressed to the interfaces and if so, they are being sent to an earlier 

60 reserved input buffer and the reservation is released when data are received from it 
by all recipients, for which they were addressed, and next information is sent to the 
LLC bridge about the frame waiting for it in the output buffer. 



Favorably data incoming to the modem are sent through the LLC bridge to an 
65 earlier reserved input buffer, and next the reservation of this buffer is released when 
all recipients, to whom they were addressed, receive data from it. 

Favorably the input buffer is controlled by setting a list of recipients for which 
the frame is addressed, and next the recipients are informed about the frame located 
in the buffer, with every informed recipient increasing the counter of informed 
70 recipients by one, and next when the recipients receive the frame from the buffer, 
the counter of receipts increases by one, and it is defined, that data were collected by 
all recipients in the time, when the coxmter of receipts is equal to the counter of 
informed recipients. 

75 The object of the invention is illustrated in the exemplary embodiment in picture, 

in which fig. 1 illustrates a block diagram of a cable modem with a multiplexer, fi: 




2 illustrates transfer of packets in the layers of the modem with the multiplexer, fig. 

3 illustrates connection of the multiplexer with the cable network side and the 
80 customer premises equipment side, fig. 4, 5 illustrate a structure of Ethemet frames, 

which are transmitted in the system, fig. 6 illustrates a structure of input and output 
buffers of the multiplexer, fig. 7A, 7B, 7C, 8, 9 illustrate a block diagram of data 
transfer in the system, fig. 10 illustrates a detailed structure of the fragment of cable 

85 modem, fig. 1 1 illustrates a block diagram of a check and associate fiinction, fig. 12 
illustrates a block diagram of an adding fimction and fig. 13 illustrates a block 
diagram of an identifying fimction. 

Fig. 1 illustrates a structure of a cable modem, the LLC bridge 113 of which is 
connected to the multiplexer 114 of interfaces 115. 116, 117 of customer premises 
equipment. Any number of interfaces 115, 1 16, 117 of devices, which communicate 
with the multiplexer 114, can be connected to the multiplexer 114 by means of 
appropriate fimctions. Multiplexer 114 has a built-in fimctionality, which allows to 
service the transfer of packets between cable network and interfaces connected to it, 
directing the received packets to appropriate interfaces. 

95 Transfer of data between cable network and customer premises equipment in the 

cable modem is illustrated in fig. 2, in which layer 200 o f LLC bridge was shown, 
layer 210 of the interfaces multiplexer, layer 230 of drivers of devices and physical 
layer 241 . The LLC bridge is responsible for servicing transfer of incoming 201 and 

100 outgoing 202 data. Incoming data 201 and outgoing data 202 are being sent through 
the multiplexer 211 of interfaces, to which interfaces 221, 222, 223 , 224 of separate 
customer premises equipment are connected, which make communication fimctions 
available between the devices driver and the multiplexer. Further data are being sent 

105 through drivers 231, 232 of separate devices. One of such drivers can be for example 



the Ethernet 231 driver, which services the queues of incoming and outgoing data 
frames. The Ethemet driver 231 of the device connects with the physical layer 241 
of a given device. Interfaces of virtual devices do not have to be connected with the 
physical layer, because these devices can be applications, servicing specific types of 
110 frames, which are being sent. Such applications can for example perform diagnostic 
functions. 

The layout of interfaces multiplexer and its connection with the cable network 
side 301 and the customer premises equipment side 302 is shown in fig. 3. From the 

115 cable network side 301 the interfaces muhiplexer 311 co-operates with the LLC 
bridge 304, the IP stack 303 , and optionally with interfaces 302 of virtual devices, 
which for example can be used for servicing control frames, transmitted in the 
system. From the side of customer premises equipment 302, interfaces of any 
devices can be connected, for example interfaces of virtual devices 322, a USB 

120 interface 323 , an Ethemet interface 324, a UART interface 325 and interfaces of all 
other devices used by the user. The only limitation is the necessity to register the 
interface in the system, by making available its data and functions, which service 
communication between the interfaces multiplexer and the device driver. 

125 In the presented solution, data in the system are transmitted in the form of 

Ethemet frames. Two types of frames can be transmitted in the system: data frames 
and control frames. 

An exemplary format of a data frame 401 is illustrated in fig. 4. Data frames 401 
130 are typical Ethemet frames, which include the address of the recipient 402 , the 
sender 403 , the frame type 404, data 405 with variable length and the field of CRC 
check sum 406. These packets are used by all interfaces as a standard. 
In turn in fig. 5, an exemplary format of a control frame 411 is presented. Contr 



frames 411 in the presented solution are also Ethernet frames, in which the address 



of recipient 412 is presented, the sender's address 413, the frame type 414, the 
control data block consisting of the field 415 defining the length of data and the 
CRC checksum block 417 . Control frames 411 are being sent both between the 
140 interfaces of virtual devices and physical ones. For example, a satellite TV decoder 
can by means of control frames appropriately control the work of a cable modem. In 
interfaces and drivers of separate customer premises equipment transmission of 
control frames can be blocked, so that they are not sent to external devices. 



145 in the system, which is a set of functions, which enable communication between the 
multiplexer and a given device. The interface registers itself by means of appropriate 
function, which registers parameters of the interface in the table of multiplexer 
interfaces. An exemplary structure, defining the interface parameters, is shown 
below: 

1 50 Typedef struct 



In order to enable a certain device to be serviced, its interface should be registered 



char 



♦device name 



/♦interface name*/ 



155 



device 



device id 



/*unique interface identifier*/ 



address 



device mac address 



/* interface MAC address*/ 



flag 



deviceflag 



160 



/* status flag: active/inactive*/ 



flag 



device_control_flag 




8 



/* accepting/rejecting control frames flag*/ 
transmit_f transmit 

/ * frame sending function*/ 
165 UpDo\vn_f UpDown 

/♦status flag controlling function*/ 
long sent_packets 

/*number of frames sent by the interface*/ 
Long received packets 

1 70 /*number of frames received by the interface*/ 

} device_handle 

After a start of the system, consecutive interfaces are initiated. At 
175 initialization, a table associating the identifiers of interfaces and MAC addresses 
allocated to them is built. MAC addresses are addresses, which identify a specific 
device in the layer of access control to media, in English Media Access Control, 
abbreviated as MAC. This layer controls low-level device protocols. According to 
180 Open System Interface network model, the MAC layer and the LLC layer (Logical 
Link Control) create the DLC layer (Data Link Control) 

An exemplary structure of a table associating identifiers of interfaces and 



MAC addresses assigned to them looks in the following way: 



Device MAC address 


Interface identifier 


Device 1 (MACl) 


Device 1 interface 


Device 2 (MAC2) 


Device 2 interface 


Device 3 (MAC3) 


Device 3 interface 


Device 31 (MAC31) 


Device 3 interface 


Device 32 (MAC32) 


Device 3 interface * . 





185 A second table, which is an interfaces table is also created in the system. This is a 
table, the columns of which determine interfaces parameters, given during 
registration of the interface in the interface structure, for example: device name, 



to registered interfaces are stored. Interface registration is performed by invoking a 
function, which reads the (struct device_handle) data structvire as a parameter and 
stores it in the interfaces table. 
Additional devices can be connected to one subscriber interface. For example, to 

195 an Ethernet interface, through a hub, a few PC-type computers can be connected. 
Each of these computers has its own MAC address. At system initialization, or 
during its operation, devices can send control packets (for example, ARP packets, 

200 the name of which comes from English definition Address Resolution Protocol). 
Then, these packets go through a proper device interface, and this interface sends 
them further on to an output buffer, from where they are fetched by a bridge. A 
proper function monitors the packets coming to the input buffer and reads the MAC 
address of the sender and the device interface identifier, from which a given packet 

205 comes. Next, it checks in the interfaces table, if the given MAC address appears in 
it. If not, it appends to the table information about the relationship of MAC address 
with the interface identifier. During further operation of the system, when packets 
designated to appropriate MAC address appear, it will be associated already with 
appropriate device interface identifier and the packet will be sent to this device. 

210 Data are sent and received by means of a buffer block 521 consisting of output 
buffers 501 and input buffers 511, the operation concept and structure of which is 
illustrated in fig. 6. Data addressed to the bridge are copied by the device interface to 
output buffers 501 and stored there until the time when the bridge sends them toAe" 



190 



device ID number, device MAC address. In the table of interfaces, data related only 



10 




215 MAC controller or the IP stack. Storage areas are reserved in the output buffer 501 
for determining the status 503 and for the frame 504 . The output buffer is reserved 
by the device interface, and released by the bridge or interfaces multiplexer. Data, 
addressed to device interfaces are copied by the interfaces multiplexer or the bridge 
to input buffers 511 and stored there by the time when all interfaces, to which these 

220 data were designated receive them. Each input buffer has its own counters: a counter 
514 of recipients, informed that a frame awaits them in the buffer, and a counter 515 
of the number of receipts of the frame from the buffer. 

225 When the counter 514 of the informed recipients and the counter 515 of the number 
of frame receipts from the input buffer 511 are equaled, the input buffer 511 can be 
released by the multiplexer and can be used once again. Besides the areas for 
counters in the input buffer 511 storage areas are reserved for determining the status 
513 and for the frame 516 . The input buffer is reserved by the interfaces multiplexer 

230 or the bridge, and released by the interfaces multiplexer. 

The procedure of sending data from the interface to the cable network, is 
illustrated in fig. 7 A and 7B. In the first step 601 the device interface requests access 
to the output buffer, sending a command of its reservation by means of the adding 

235 fimction to the buffers management block and when a buffer is available, it receives 
as a retum parameter a pointer to the reserved buffer. The output buffer will be 
released when the bridge sends the frame to the MAC controller, or when it proves 
that sending data to the bridge is blocked. In the next step 602, the interface copies 
the frame to the output buffer through a direct way. The fiirther part of the procedure 

240 is performed by a buffers management block. Thus in step 603 the type of the sent 
frame is checked. If it is a frame designated to one device (unicast), in step 604 a 
check is made if the frame, being sent is addressed to a device connected to 

11 \ 




245 interface. If so, or if the frame is addressed to many devices (multicast, broadcast), 
in step 605 a check is made, if there is a possibility to send data to interfaces, while 
enabling or blocking data sending is controlled by meeins of an appropriate flag. If 
so, the procedure requests access to input buffer and when the buffer is available, it 
reserves this buffer in step 606. Next in step 607 it copies the frame, being sent, to 

250 this buffer. Next in step 607 a list of recipients of this frame is determined by means 
of providing their MAC addresses. If the frame is designated to one device (unicast), 
there is only one recipient on the list. If this is a frame designated to many devices 
(multicast, broadcast), there will be all devices on the list with MAC addresses 

255 available in MAC/CPE table. In step 623 a send takes place to the first recipient on 
the list by means of a check and identifying function, information (pointer to buffer) 
about the frame assigned to it, waiting in the input buffer. The counter of informed 
recipients is increased by 1 in step 624. and in step 625 the procedure checks, if all 

260 recipients were informed. If not, it tums to next recipient in step 626. When all 
recipients were informed, or when the frame is not sent to interfaces, the procedure 
checks in step 610 , if the frame can be sent to the LLC bridge (by means of an 
appropriate flag, sending data to the bridge can be enabled or blocked). If so, in step 

265 612 the buffer address, in which a frame awaits it, is sent to LLC bridge. After the 
bridge fetches the frame from it, it will release the buffer for next use. The buffer 
can also be released by interfaces multiplexer in step 611. if the frame is not being 
sent to the bridge. Next in step 613 the reception of data from the input buffer is 
checked, which is performed by the procedure from fig. 7C. 

270 The procedvire of checking data reception from the input buffer, which is 

illustrated in fig. 7C, starts in step 631 from making the local counter of informed 
recipients available to interface functions. Next, in step 632 it is checked 

12 




recipients received the frame, by comparing the counter of informed recipients and 
275 the counter of the number of receipts. If so, then in step 633 the input buffer is 
released. If not, the procedure is finished in step 634 . and the input buffer will be 
released by the function collecting data from the buffer as the last one. 

When the bridge receives the frame, it proceeds further like a typical bridge of 
cable modem, which means that it directs the frame to the side of the cable network. 
280 Operation of the bridge is not relevant for this description. 

The procedure of data reception is illustrated in fig. 8. In step 701 the bridge 
requests access to the input buffer and when it is available, it reserves this buffer. 
Next in step 702 the frame is sent to the input buffer, and in step 703 the procedure 
of the buffer management block checks, what type of frame this is. If the frame is 
designated to one recipient (unicast), in step 704 the recipient of the frame, is 
determined by means of determining the MAC address of the recipient. Next in step 

705 . it is checked in the MAC/CPE table, if this recipient is available. If yes, in step 

706, information (a pointer to a buffer) will be sent to it about the awaiting frame 
290 (by means of the check and associate function and the identifying function), and the 

counter of informed recipients is increased by one in step 707. If this is a frame 
designated to many recipients (multicast/broadcast), in step 709 the list of frame 
recipients is determined, while on the list there are all active MAC addresses 

295 located. In step 710 information about the frame, waiting in the input buffer, 
assigned to the first recipient on the list is sent to it, and the counter of informed 
recipients is increased by 1 in step 711 . In step 712 the procedure checks, if all the 
recipients were informed. If not, it comes to the next recipient in step 713 . After all 
recipients were informed, in step 708 data reception from the input buffer is 

300 checked, which is performed by the procedure illustrated in fig. 7C. .j^^^^^^^^^^^'^^^^ 



When the interface of the device is informed about a frame waiting for it in the 

305 input buffer, which means that it receives an pointer to this buffer in the same time, 
it starts its procedure of frame collection, which is illustrated in fig. 9. Therefore in 
step 801 the procedure collects the frame from the input buffer in a direct way, 
because it knows its address and sends it to the device. Next, in step 802 the counter 
of the number of frame receipts from this buffer is increased by 1 and in step 803 the 
interface checks if all the recipients collected the frame by comparing the counter of 

310 informed recipients and the counter of the number of receipts. This check takes 
place, if the counter of informed recipients was made available earlier for this 
function. If not, the check is not performed. If all recipients have collected the 
frame, it means that this function received the frame as the last one and releases the 
input buffer in step 804. If not, the procedure is finished in step 805, and the input 

315 buffer will be released by the ftinction of other interface. 

Fig. 10 shows a ending part of the LLC bridge 913, the interfaces multiplexer 914 
and a set of CPE interfaces 915 c onnected to it, which consists of interfaces 909, 
910, 911, 912 . The ending part of the LLC bridge 913 comprises a block of input 

320 buffers 901 , storing data addressed to CPE interfaces and a block of output buffers 
902, storing data sent by CPE interfaces, and also a buffer management block 903, 
which performs buffer reservation and release functions. However the interfaces 
multiplexer 914 comprises a MAC/CPE 904 table, a check fiinction, which checks in 

325 the MAC table, if there is a device with a MAC address, defined in the packet, 
connected to the modem and if yes, it sends the packet fiirther, and if not, it rejects 
this packet. The interfaces multiplexer 914 comprises also an adding ftinction 906 , 

330 which analyzes information incoming to CPE interfaces and checks if sender's MAGi^^r^rr:-^ 

//^ ^ ^ ^ 



address is stored in the MAC table, and if not, it adds it to this MAC table. The 
interfaces multiplexer 914 comprises also an interfaces table 907 and an identifying 
function 908, which basing on the CPE identifier transmitted by the check and 
associate function 90S, collects from the table of interfaces 907 data identifying a 
specific interface and sends specific information to it. 
The check and associate function, the block diagram of which is illustrated in fig. 

335 1 1, in step 920 as an input parameter reads the MAC address, to which the packet is 
designated. Next in step 921 it checks, if in the MAC/CPE table there is a record 
related to such MAC address. If not, this means that the given MAC address is not 
served by the interfaces multiplexer, which means that no device with such MAC 

340 address is visible by the multiplexer and in step 922 there is a rejection of the packet. 
In case the function reads the identifier of the CPE address, to which a device, with a 
given MAC address is connected, in step 923 the CPE identifier is read, and next in 
step 924 this identifier is given, which allows information to be sent to appropriate 
interface. 

345 In fig. 12 a block diagram of the adding function, which analyzes information sent 
from CPE interfaces to the LLC bridge, is presented. For each information sent, after 
reading the MAC address of its sender in step 930. there is a check in step 931 if in 
the MAC/CPE table there is already such MAC address present. If not, in step 932 it 

350 is added to the table together with information, from which CPE interface this 
packet came. If the MAC address is already in the table, in step 933 no actions are 
taken. 

Fig. 13 shows the identifying function, which in step 940 is read by the CPE 
identifier, to which the sent frame is designated. Next, in step 941. in the interfaces 
355 table (in which information is stored about registered interfaces) it finds a fimctipassrsr::^^^ 



of a given interface, which will send data to it, and next in step 942 it sends the 
frame to this function, and the function transmits it to the given interface. 

In the modem, information is transmitted in various paths depending on the type 

360 of information, which is sent. Therefore, messages about the packet for a specific 
MAC, which waits in a specific buffer is sent through a path to input buffers by 
management block and control function to a CPE interface. Data collected by 
interfaces from a specific buffer are sent directly between input buffers and CPE 

365 interfaces. In tum, requests of reservation of the buffer and messages of releasing a 
buffer (except for adding function) are transmitted through a path from CPE 
interfaces through adding function and management block to output buffers. 
However, data sent through interfaces to a specific buffer are sent directly between 
output buffers and CPE interfaces. 

370 The solution, presented above allows coimecting directly to the modem any 
number of interfaces of different type of physical devices, for example PC 
computers or digital TV decoders, connected through USB or Ethernet or a serial 
port. The above solution allows also connecting directly virtual devices, for example 
applications servicing control frames, transmitted across the network. 
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Patent claims 

1 . A broadband modem including a system of servicing MAC physical layer, LLC 
bridge, with which the physical layer system communicates and IP stack 
responsible for processing IP packets, with which the LLC bridge co-operates, 
characterized in that the LLC bridge (113^ is connected with interfaces 
multiplexer (115. 116. 117 . 909. 910. 911. 912) the customer premises equipment 
multiplexer (114) connected to interfaces multiplexer (114). enabling to send data 
between the LLC bridge (113^ and one of the interfaces (115). ( 116. 117 . 909. 910 . 
911 . 912) of customer premises equipment and possessing interfaces table (907), 
in which data of registered interfaces (115, 116, 117, 909, 910, 911, 912) are 
recorded, based on which by means of identifying function ( 908 ) the interface is 
determined, to which a frame with a specific physical address of recipient is 
designated and MAC addresses table (904) of devices with interfaces identifiers 
( 115 . 116 . 117 . 909, 910, 911, 912 ). to which these devices are connected, while 
the interface identifier, to which the device, with determined MAC address is 
connected is determined by check and associate function (905), and records to this 
table are added by means of adding function (906 ). which analyzes commands, 
sent by interfaces (115. 116. 117. 909. 910. 911. 912) . 

2. A broadband modem according to claim 1, characterized in that the interface 
(115. 116. 117. 909. 910. 911. 912) is the interface of a physical customer 
premises equipment, controlling transmission of data between the multiplexer and 
the driver of this device. 



2 



3. A broadband modem according to claim 1, characterized in that the interface 
30 (115. 116 , 117, 909 , 910 , 911 , 912 ) is the interface of virtual customer premises 

equipment, which is the application, operation of which depends on the received 
packets and which controls transmission of data between the multiplexer and this 
application. 

4. A broadband modem according to claim 1, characterized in that the table of 
3^ interfaces (904) determines the name of the device, the ID number of the device, 

the MAC address of the device. 

5. A method of controlling data transfer between the cable modem and customer 
premises equipment, connected to cable modem, characterized in that the modem 
is equipped with interfaces multiplexer, to which the customer premises equipment 
interface is connected, while the interfaces multiplexer has an interfaces table, 
based on which the interface identifier is determined, to which a frame designated 
to customer premises equipment with a specific MAC address is sent. 

45 6. A method of controlling data transfer according to claim 5, characterized in that 
the data outgoing from the modem are sent first through the customer premises 
equipment interface to the output buffer, and next it is checked if they are 

50 designated to the interfaces and if so, they are sent to earlier reserved input buffer 
and reservation is released when data are received from it by all recipients, to 
which they were designated, and next information is sent to the LCC bridge about 
the frame in the output buffer, waiting for it. 

55 7. A method of control of data transfer according to claim 5 characterized in that 
the data incoming to the modem are sent through the LLC bridge to earlier 
reserved input buffer, and next reservation of this buffer is released when the data 
are received fi-om it by all recipients, to which they were designated. 

60 8. A method of data transfer control according to claim 5, characterized in that the 
input buffer is controlled by setting a list of recipients for which the firame is 
designated, and next recipients are informed about the frame located in the buffer, 
with each informed recipient the counter of informed recipients is increased by 
one, and next when the recipients receive the frame fi-om the buffer, the counter of 
receipts is increased by one, and it is determined that the data were received by all 
recipients in the time when the counter of receipts is equal to the counter of 
informed recipients. 
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